1. Field of the Invention
The present invention relates to computer systems. More particularly, the present invention relates to a method for representing an application programming interface (API) in an object-oriented system such that submerged hierarchies are enabled.
2. Background
An API definition file typically defines a library of functionality that may be used by one or more client applications in an object-oriented system. An API definition file also typically includes the set of classes and interfaces that are externally accessible from that library and the items in those classes and interfaces that are externally accessible. A library in Java™ technology corresponds to the Java™ “Package” construct.
The “items” in classes and interfaces include fields, methods and implemented interfaces of the various classes, and fields and methods of the various interfaces. Additionally, the immediate superclass and superinterface for each class and interface, respectively, is listed. Since an API can only enumerate externally accessible items, all superclasses and superinterfaces must also be externally accessible.
An API definition file may include non-public functionality that is not exposed by the API definition file. This functionality can be implemented in classes as non-public fields, non-public methods or non-public implemented interfaces. In addition, the content of a method is not disclosed in an API representation, regardless of whether the method is public or non-public. Therefore, non-public algorithms are not disclosed.
FIG. 1A illustrates a typical API representation. In this example, all of the classes in the hierarchy of C2 (2) are public. The API representation indicates that the public class C1 (4) is the superclass of the public class C2 (2). The API representation also indicates that the public class Object (6) is the superclass of the public class C1 (4). Thus, this API representation reveals the entire hierarchy of C2 (2). Furthermore, typical API representations unnecessarily constrain a hierarchy by forcing the hierarchy to contain only public classes.
Additionally, since typical API representations only indicate the immediate superclass or superinterface of a particular class or interface, respectively, one must traverse the hierarchy recursively to determine whether a class or interface is a member of the hierarchy. Such functionality requires that not only the immediate API definition file is available when validating references to elements in a hierarchy, but also the set of API definition files referenced by that API definition file.
The Java™ language supports a construct where the immediate superclass or superinterface of a class or interface, respectively, may be declared as non-public. A superclass or superinterface declared in this way must not be disclosed in an API definition file. FIG. 1B demonstrates this feature in a class hierarchy. Such a hierarchy that includes one or more non-public classes is referred to as a submerged hierarchy. Such constructs are useful to API designers and implementers because they allow non-public, or proprietary functionality to be inserted into a hierarchy and for that functionality to be encapsulated in a hidden class. This provides for modular designs consistent with Object-oriented theory.
However, the hierarchy illustrated in FIG. 1B cannot be represented in a typical API definition file. This is because a typical API representation requires the disclosure of the immediate superclass of C2 (8), which is PrivateClass (10). Disclosing a non-public class such as PrivateClass (10) would violate the Java™ language requirement that such a class not be made public.
Typical API representations constrain the design of an API such that more than is desirable falls into the publicly accessible domain. Accordingly, a need exists in the prior art for an API representation that sufficiently constrains particular implementations, while allowing them to define submerged hierarchies.